如果2 ^ 32还不够怎么办？

如果你在一个表中有这么多条目,那么2 ^ 32对于你在给定时期内(一天,一周,一个月......)的auto_increment ID是不够的呢？
如果MySQL提供的最大数据类型是不够的怎么办？

我想知道我应该如何解决我的表中添加了如此多的条目需要唯一ID的情况,但是我在一段时间内填写了我的数据类型？

我如何能够在MySQL(或任何其他系统)内部实现无限量的唯一ID,或至少以指数方式增加它？

理想情况下,我会期待类似的东西

> SELECT * FROM table;

+---+------+
| a |  b   |
+---+------+
| 1 |  1   |
| 1 |  2   |
| 1 |  3   |
|...| .... |
|...| .... |
| 1 | 2^32 |
| 2 |  1   |
| 2 |  2   |
+---+------+

这会以指数方式增加条目数量.

你如何应对这种情况？
请记住 - 要求是为任何条目提供唯一ID.

你认为BIGINT UNSIGNED不够吗？这是一个0 - 18.446.744.073.709.551.615的范围,或一年50.539.024.859.478.223条目每天(365 d/y),每小时2.105.792.702.478.259条目,每分钟35.096.545.041.304条目或每秒584.942.417.355.

假设每秒600次写入(没有任何读取),您可以以完全写入速度写入条目974.904.08年.那应该够了.

您可以使用BIGINT作为主键.默认情况下,这是一个64位数字.

编辑#2:显然我之前所说的关于改变BIGINT字节长度的内容是不正确的.BIGINT 被固定在一个8字节的限制.

只需使用128位密钥.不需要无限数量的键,因为您可以非常快速地允许更多行,而不是宇宙中的原子数.(大约256位).

如果您有太多数据可以解决此问题,那么选择主键可能是您最不关心的问题.

如果您正在使用InnoDB引擎,那么选择一个您经常搜索的主键(特别是在搜索返回多行的情况下)可能有助于提高性能,因为它会对主键进行聚类,从而使范围扫描更好.

我首先移动到BIGINT 2 ^ 64.GUID将是另一种选择,但您需要以"某种形式"自己存储这些选项